• Instructions.cs is generated from Instructions.tt; please don't modify the former manually. (instead, use CustomComputeFlags in the .tt and a partial class for the actual implementation)
• SetChildInstruction already invalidates the flags; so there's no need for your added InvalidateFlags() call.
• box not having any side-effects despite doing a heap-allocation, seems a bit questionable. But I don't see how it could cause any real issues (as the heap-allocation cannot be accessed without depending on the result of the box instruction, so incorrect reordering of heap-accesses still seems impossible).
• I don't really like the InferType call in the low-level flag computation -- that seems like something that might risk infinite recursion. Maybe just restrict this to box T(default.value T)?

Or maybe we don't need the type comparison at all -- if it's OK to ignore the heap-allocation and heap-write in some cases, it might also be OK to do so in all cases?
The argument that no problematic reordering is possible because the heap allocation is not otherwise accessible, doesn't depend on Argument.Flags == None or the type comparison...

I rebased, and CI is now failing, but I don't think that's my fault. It appears that CI has failed on every commit since #3594, though that might be a coincidence since I also saw github/codeql-action#3208 and github/codeql-action#3207 which claim that the release of .NET 10 RC2 caused the issue.

As long as the "Build ILSpy" action runs fine in debug and release there is no need to worry.

CodeQL has not once reported anything. @christophwille why do we have the action set up in the first place? I think, maybe it would make sense to just remove it completely?

The intent for it is to report nothing - it would be bad IF at some point it actually found some vulnerability.

@dgrunwald Can this be merged?